										BRed
							     Be Resource editor
								   Version 1.0 b1


What is BRed?

BRed is an engine for editing BeOS file resources.  BRed does no editing on its own.  It
works with plugin editors that do the editing.  BRed provides a consistent method for
handling resource data, and passes that data onto the editors, shielding them from the
filesystem and book-keeping tasks.


What is the current state of BRed?

The current version is 1.0b1 (beta).  There is still much work to do on it; however, it
should provide a stable enough environment for additional editors to be written and for
developers to actually create resource files and data for their applications.

Future versions of BRed will greatly improve in stability and features.  There are a
number of known problems (see below) that will be fixed.  At the time of first distribution,
there is only one editor (for the APPI type).


Why are you releasing BRed with only one editor and that many problems?

To put it simply, because many developers have expressed interest in it.  From personal
experience and comments from other developers, a resource editor is an essential tool for
development.

At the time of distribution, only a basic APPI editor was written.  Initially, this was
written to test the BRed engine and management routines, plus the plugin API.  However,
I have also provided the source for the APPI editor so that developers can build other
plugins that they need.  I will be preparing some more formal documentation that explains
how to use BRed and in detail how to write plugin editors.


What is the cost for this (half-finished) tool?

Initially, I was going to make this program shareware.  However, this version is freely
available and cost you nothing.  Repeat, no $$$.

Why?  Well, primarily because of the limitations I note above  it is beta, it is only
moderately stable, it is not documented well, and there is only one editor provided.  I've
released it because numerous developers have been asking for it.  But I've also provided
this version at no cost because of these limitations.  Over time, these will go away.

Future versions of BRed will most likely be shareware and available for a reasonable price.
But future versions will be much more stable, have many more editors and support code
provided, and several other features.


What is coming in the future for BRed?

A better, cleaner API (similar to the current but expanded).  Templates.  A resource
language.  Numerous plugins (including types that mimic the Macintosh resources of MENU,
DITL, TEXT, and more).  Super-stability and file protection.

If you want more details, please feel free to contact me with your questions..


Speaking of questions, where can I get more information on BRed?

I apologize for the lack of documentation.  This is being remedied as we speak. In
particular, keep a watch on the Ground Cover Software web page:

	http://hoopy.nurk.com/~gcs/

(Pardon the strange hostname).  Currently, very little exists at this website, but I will be
putting things together very soon.  If you have questions, concerns, comments, or bug
reports for BRed, please send email to:

	gcs@hoopy.nurk.com		(preferred)
	moss@hoopy.nurk.com


You mentioned known problems.  What are they?

You asked for it.  Here is the list of problems I've encountered.  Please make sure to
submit any bugs you find to the above email address.

Overall, BRed is fairly stable.  However, there are certain (not always easy to reproduce)
conditions that will cause it to crash.  Word of warning:  it is safer to work on a copy of
your file.  If you crash with a file open, the file will not be closed and it will become
corrupted.

Several menu commands are greyed out.  They won't ever enable in this version (they are
there for future expansion).

The selection window that appears when creating (Alt-K) a new resource is ugly and not
keyboard navigable.  It also has a nasty CPU-eating loop while it is open.

The colors in the resource list have meaning.  Black means nothing has changed in that
particular resource.  Pale green means the resource has been added.  Red means it has been
removed.  Blue means it has changed.  These changes are committed (and theitems return
to black) when the file is saved.  There are some potential cases (that I can't reproduce)
when the coloring goes wrong.

You can save the file to commit all changes or close without saving to ignore all changes.
The "Commit One Item" button/menu option is missing.  You'll see that later.

There is a blank area at the bottom of the document window, and the resize box leaves
tracks when resized.

Resource names cannot be set (although preexisting names will be preserved).  Neither
resource names nor IDs can be changed for any resources.

There is no current way to cut and paste nor drag and drop.

If you create a new file, add some resources, then hit the close button, an alert will appear
asking if you want to save your changes.  Selecting "Close, Save Changes" will first bring
up the save-file panel, then will commit all changes back to this new file, but won't close
the document.  Click the close box (or type Alt-W) again to close it.  This only happens
with new files.

In the APPI editor, the Add button should be enabled only when four characters have been
typed into the field above it.  Incorrectly, it is always enabled.

Don't hit the APPI editor's Add button unless four characters are typed into the field above.  Otherwise, you crash and burn.

The APPI editor is not smart enough to realize that, if the type list contains the same data
but in a different order, then overall the data is the same.  It will mark it blue (changed)
and you will be asked to save when you attempt to quit or close the document.

When closing a document while editors are still open, the editors should be automatically
closed.  However, there may be situations where this won't happen, and trying to continue
editing when the file/document has been closed is not a good idea.

There's no documentation.  I'm working on it.


														      1996, Ground Cover Software
 